練武不僅在於招式，更在於貫通經脈的內功。六日已過，該是回顧的時候。若只會出招而不懂融會貫通，則遇到變化難以應付；今日我們便將前六天所學，化為完整的體系，並引入「風險管理」作為最佳實踐。

首先，我們從「唯快不快」作為出發點，主要是說明當 AI 產生的測試程式碼與我們自己撰寫的風格與架構一致的時候，便等於多了另一個人力撰寫測試程式碼，讓自己能夠成為擁有兩倍的 10x 工程師。以目前 AI 雖然能夠協同我們撰寫程式碼、甚至能夠幫助我們生成測試案例，但無法完全了解整個產品的邏輯，建議測試案例目前還是要由自己把關比較好，免得遺漏掉關鍵的測試案例或是測試情境。

接著，我們開始學習如何運用 Playwright 這個現代 E2E 框架，撰寫第一個測試案例。這就像是學會了最基礎、卻最實用的第一式，同時也介紹什麼是測試情境(Test Scenrio)，雖然我們還沒有深入探討測試案例與測試情境在產品開發週期理扮演什麼樣子的角色，我們先透過 Gherkin 語法，把需求用自然語言串成招式，讓技術與非技術的人都能共用同一套語言，讓我們可以對齊功能需求，但其實也是與 AI 溝通，讓 AI 理解測試情境。

到了第三日，我們安裝好 GitHub Copilot 與 Playwright MCP，就像打通了任督二脈，從此能將腦中的意圖化為程式碼，從這天開始，我們可以透過與 GitHub Copilot Chat 協同開發。為了讓 AI 能夠依照我們的規範撰寫程式碼，我們透過 .prompt 與 .chatmode 讓 AI 能夠撰寫跟我們風格一致的程式碼，也讓之後的程式碼能夠易於維護和閱讀。

第五天和第六天，我們先前撰寫的測試情境，使用 .prompt 和 .chatmode 示範如何協同撰寫測試程式碼，接著在用一個 RESTFul 服務的例子，以測試金字塔原則為基準，從單元測試、整合測試到 E2E測試，一層一層描述其目的與功能，讓每個功能都可以確認其功能正常。

這六日的功課，其實都是分散的點，背後都有常見的概念，例如：AI Agent、Playwright 的使用、測試金字塔、SBE(specific by example)和 BDD(Behavior-Driven Development)等等。

接下來，我們將會更深刻了解撰寫自動化測試常使用的 Pattern，就像是獨孤九劍的九式。